[% setvar title The Perl 6 Summary for the week ending 20030316 %]
<div id="archive-notice">
    <h3>This file is part of the Perl 6 Archive</h3>
    <p>To see what is currently happening visit <a href="http://www.perl6.org/">http://www.perl6.org/</a></p>
</div>
<div class='pod'>
<a name='The Perl 6 Summary for the week ending 20030316'></a><h1>The Perl 6 Summary for the week ending 20030316</h1>
<p>Spring is in the air, the Apocalypse is here (or imminent, depending
on which sense of the word 'Apocalypse' you are using). We'll start
with perl6-internals as usual, before bracing ourselves for the
increased volume and ploughing on into perl6-language.</p>
<a name='Object Spec'></a><h2>Object Spec</h2>
<p>Dan's 3rd try at the Objects and Classes spec received a very small
amount of further discussion this week. What there was mostly touched
on the boundary between where the line is drawn between parrot's
object system and a particular language's object system. The
inference I draw from all this is that the next Object spec will be
the final(ish) Parrot Object spec.</p>
<a name='Parrot 0.0.10'></a><h2>Parrot 0.0.10</h2>
<p>Steve Fink instituted a Parrot feature freeze in the run up to 0.0.10
at the end of last week, aiming for a release on Saturday the 15th of
March and noted that he was leaning toward &quot;Juice&quot; as a code name
(punning on Leo T&ouml;tsch's work on the <code>imcc -Oj</code>
optimizations). David Cuny pointed out that there was already a
virtual machine called Juice and suggested a whole list of possible
code names. Leo T&ouml;tsch reckoned that calling it 'Juice' would be
'too much honour' and suggested a list of anagrams of 'Parrot
ten'. (&quot;Partner to&quot;, &quot;Par Rotten&quot; or &quot;Tarte porn&quot; anyone?).</p>
<p>It looks like we missed the release on the 15th, but Steve announced
a release candidate on the 16th, in expectation of a release on the
17th.</p>
<p><a href='http://groups.google.com/groups?threadm=20030309225740.GA662@foxglove' target='_blank'>groups.google.com</a> -- Feature freeze</p>
<p><a href='http://groups.google.com/groups?threadm=20030316091856.GB662@foxglove' target='_blank'>groups.google.com</a> -- Release candidate announced</p>
<a name='languages/BASIC reorg'></a><h2><b><i>languages/BASIC</i></b> reorg</h2>
<p>Clinton A Pierce announced that he'd reorganized the
<b><i>languages/BASIC</i></b> subtree into 'compiled' and 'interpreted'
subtrees and noted that he was very impressed with the improvements in
Parrot's speed and memory management. Leo T&ouml;tsch pointed out a
few issues with MANIFEST and the need for a Makefile, and wondered if
Clinton had run things through IMCC.</p>
<p><a href='http://groups.google.com/groups?threadm=5.1.0.14.2.20030309181336.03b10b10@mail.geeksalad.org' target='_blank'>groups.google.com</a></p>
<a name='The Judy algorithm'></a><h2>The Judy algorithm</h2>
<p>Tim Bunce pointed everyone at the Judy dynamic array code on
Sourceforge and wondered if it would be useful for Parrot. (Judy is a
high speed dynamic array implementation optimized for modern
processor architectures apparently). Leo T&ouml;tsch thought it
looked interesting and suggested that someone try wrapping Judy up in
a PMC and running some performance tests. Elizabeth Mattijsen went and
took a look and reported some issues with memory leakage and worried
that the project looked 'silent'. Tim mailed her concerns to
Judy's author who addressed them in his reply and admitted that he
wasn't that good at keeping the website up to date. He said that Judy
had been 'tested carefully not to have leakage' and wondered if it
might have been an issue with the tool Liz used to do the testing.</p>
<p>I await further developments with interest. If Judy can be made to
work, it looks jolly quick.</p>
<p><a href='http://groups.google.com/groups?threadm=20030310103730.GG25543@dansat.data-plan.com' target='_blank'>groups.google.com</a></p>
<p><a href='http://judy.sourceforge.net/application/10minutes.htm' target='_blank'>judy.sourceforge.net</a></p>
<a name='Yet another iterator proposal'></a><h2>Yet another iterator proposal</h2>
<p>Leo T&ouml;tsch posted a request for comments on what he called 'yet
another iterator proposal'. Nobody commented. I wonder if this means
everyone liked it.</p>
<p><a href='http://groups.google.com/groups?threadm=3E6CAC8F.4010308@toetsch.at' target='_blank'>groups.google.com</a></p>
<a name='Parrot for Windows'></a><h2>Parrot for Windows</h2>
<p>Benjamin Goldberg wondered if there were any precompiled parrot
binaries for Win32 available as he wants to be able to test parrot
code without the current weird rites he has to go through (see his
post for details). Clinton A Pierce put a snapshot build up on his site
temporarily for Benjamin to download. Robert Spier offered space on
www.parrotcode.org for a windows build when the next release comes out
which Dan thought would be really cool. Dan also wondered about making
an automated build farm but I think he may have a tuit shortage when
it comes time to actually implement it. Joshua Hoblitt also offered to
host binaries on his CPAN mirror. Clint said he'd be happy to make
milestone binaries and wondered if there was a standard way such a
distribution should be put together.</p>
<p><a href='http://groups.google.com/groups?threadm=3E6D7C66.3327A18F@earthlink.net' target='_blank'>groups.google.com</a></p>
<a name='Moving to PIO'></a><h2>Moving to PIO</h2>
<p>J&uuml;rgen B&ouml;mmels continued to make Dan happy by moving more
file related opcodes from STDIO to Parrot's PIO libraries. The latest
ops to get his attention were <code>open</code> and <code>close</code>. Dan did a happy
dance and applied the patch before wondering if we were subject to a
code freeze (I don't think so; it was feature freeze time).</p>
<p><a href='http://rt.perl.org/rt2/Ticket/Display.html?id=21536' target='_blank'>rt.perl.org</a></p>
<a name='IMCC and PDD03 (Calling conventions)'></a><h2>IMCC and PDD03 (Calling conventions)</h2>
<p>Leo has been thinking some more about the parrot calling conventions
described in Parrot Design Document 3 and worried that they can't
actually be done. He proposed reducing the number of parameters that
can be passed in registers in order to take pressure off the register
allocator in IMCC. Dan agreed and quickly changed the PDD to take this
into account. Leo then asked for some clarification on a couple of
other issues that he was having a hard time understanding. Dan said
that it was probably best to come back to these issues after he'd done
PDD15 (The object spec). Leo agreed that objects will probably shed
more light on the calling conventions and we all sat back to hang on
Dan's every object oriented word. Not that there's any pressure at
all.</p>
<p><a href='http://groups.google.com/groups?threadm=3E6F6860.4030103@toetsch.at' target='_blank'>groups.google.com</a></p>
<a name='Parrot extensions, or PMC versatility'></a><h2>Parrot extensions, or PMC versatility</h2>
<p>Darren Duncan had some questions about PMCs and parrot extensions and
what he should consider as he wrote a general persistence library. Dan
and Benjamin Goldberg had some answers.</p>
<p><a href='http://groups.google.com/groups?threadm=p05111b00ba970ad339b0@' target='_blank'>groups.google.com</a>[24.70.202.54]</p>
<a name='sun4 vtable JIT support'></a><h2>sun4 vtable JIT support</h2>
<p>Jason Gloudon posted a patch adding support for vtable calls in the
sun4/JIT and added support for some more ops. There appeared to be a
few problems with the patch so it hasn't been applied yet.</p>
<p><a href='http://groups.google.com/groups?threadm=rt-21577-53666.4.91616196911266@bugs6.perl.org' target='_blank'>groups.google.com</a></p>
<a name='A fish, a barrel and a running joke'></a><h2>A fish, a barrel and a running joke</h2>
<p>Leon Brocard made maintaining this particular running joke almost
trivial this week by actually posting something. He's implemented
uniq(1) in parrot assembly, though he notes that it's not very fast
compared to GNU uniq(1) yet. Dan added it to the distribution in
<b><i>examples/assembly/</i></b>.</p>
<p><a href='http://groups.google.com/groups?threadm=rt-21588-53714.14.8561040030741@bugs6.perl.org' target='_blank'>groups.google.com</a></p>
<a name='Parrot reaches another milestone'></a><h2>Parrot reaches another milestone</h2>
<p>Dan has decided that Parrot has reached the point where it should have
a working <code>install</code> make target. He asked for someone to make it
so. No takers so far, but he posted late on Sunday so maybe there will
be news of this in the next summary.</p>
<p><a href='http://groups.google.com/groups?threadm=a0521060bba9a52cb54c4@' target='_blank'>groups.google.com</a>[63.120.19.221]</p>
<a name='Meanwhile, over in perl6-language'></a><h1>Meanwhile, over in perl6-language</h1>
<p>perl6-language saw 210 messages this week. Which I think is more than
it's seen in the last 3 or 4 weeks put together. Maybe it had
something to do with the return of Damian Conway and the release of
Apocalypse 6 (and the spectacularly short Apocalypse 7).</p>
<a name='Statement modifiers'></a><h2>Statement modifiers</h2>
<p>Matthijs van Duin wondered if the issue of multiple statement
modifiers has been settled. The thread is long, and the answer is
essentially (and authoritatively) &quot;Yes, it's settled. No, you can't do
it.&quot; So, unless Larry changes his mind the point is moot. However,
Matthijs does put his case very well, if you're interested in this
area I can recommend reading the thread.</p>
<p><a href='http://groups.google.com/groups?threadm=20030310095221.GC18286@cds.nl' target='_blank'>groups.google.com</a></p>
<p><a href='http://archive.develooper.com/perl6-language@perl.org/msg09331.html' target='_blank'>archive.develooper.com</a></p>
<a name='Just when you get fed up of waiting for the Apocalypse...'></a><h2>Just when you get fed up of waiting for the Apocalypse...</h2>
<p>Two come along at once.</p>
<p>Apocalypses 6 and 7 appeared online on Monday, a mere 9 months since
the last one (Apocalypse 7 is all of two sentences long and is
contained within Apocalypse 6, we'll be ignoring it from now on). This
Apocalypse covered closures, subs, functions, methods, types,
signatures and pile of other good stuff. All the syntax introduced was
spelled out neatly using Perl 6 rule notation, neatly showing off the
power of the syntax introduced in Apocalypse 5. I would attempt to
summarize it, but it's already pretty dense so I suggest you all read
it:</p>
<p><a href='http://www.perl.com/pub/a/2003/03/07/apocalypse6.html' target='_blank'>www.perl.com</a></p>
<p>Now you've digested that, the rest of the summary should be easier to
follow.</p>
<p>Damian returned to the list, though he's only reading posts related to
Apocalypse 6 and he's pretty busy writing Exegesis 6 too so we're not
expecting vast amounts of posts from him.</p>
<p>Austin Hastings kicked off with the first question, wondering if the
's' in <code>&lt;psiglet&gt;</code> was silent. &quot;Of course not.&quot; says Larry.</p>
<p>Paul applauded the new <code>macro</code> feature (but Damian corrected his
syntax).</p>
<a name='S&amp;M vs. B&amp;D'></a><h2>S&amp;M vs. B&amp;D</h2>
<p>Uri Guttman, displayed entirely too much knowledge about the
difference between B&amp;D and S&amp;M asking if Larry shouldn't have used B&amp;D
where he used S&amp;M in the apocalypse. Austin Hastings knows too much
too it appears, commenting that it depends on whether you consider
strongly typed compile-type semantics as being restrictive or
painful.</p>
<p><a href='http://groups.google.com/groups?threadm=x7el5eoq8c.fsf@mail.sysarch.com' target='_blank'>groups.google.com</a></p>
<a name='Can &quot;is&quot; properties be specified indirectly?'></a><h2>Can &quot;is&quot; properties be specified indirectly?</h2>
<p>Austin Hastings wondered if there would be some way of differentiating
between an array of constants and an array of variables. In other
words, how would one specify an array which may be appended/pushed,
but whose values cannot change or a hash to which you could add keys
but not change existing entries. Damian thought that you'd have to
subclass Array or Hash as appropriate. Luke Palmer wasn't keen on this
because then it would be easier to do something in C++ than in Perl,
which isn't the usual way of things.</p>
<p><a href='http://groups.google.com/groups?threadm=20030310221737.97547.qmail@web12307.mail.yahoo.com' target='_blank'>groups.google.com</a></p>
<a name='is constant eq pass by value?'></a><h2><code>is constant</code> eq pass by value?</h2>
<p>Uri Guttman was confused by the default parameter passing style for
Perl 6 functions, <code>is constant</code>. A parameter variable declared with
<code>is constant</code> is 'locked'; you can't use the same variable to hold a
different value.</p>
<pre>   sub some_func ($some_arg is constant) {
       $some_arg += 10;
       ...
       return $some_arg;
   }</pre>
<p>To do that you need to declare the parameter with <code>is copy</code>. Uri
noted that he really should keep his finger off the send button until
he's read the whole 'megilla', whatever one of those is.</p>
<p><a href='http://groups.google.com/groups?threadm=x74r6aomdr.fsf@mail.sysarch.com' target='_blank'>groups.google.com</a></p>
<a name='Pipes'></a><h2>Pipes</h2>
<p>Michael Lazzaro declared that he thought the Apocalypse was <i>great</i>
and that the 'sig stuff is very, very nice.' Then he asked about
'pipes' (the new <code>&lt;==</code> and <code>==&gt;</code> operators which are almost,
but not quite, entirely unlike the hypothetical <code>~&gt;</code> and
<code>&lt;~</code> operators that were discussed so interminably a few
summaries back). He wanted to know what was decided about some of the
edge cases discussed in the appendix to the apocalypse (and had a
comment to make about style). Damian pointed out that Michael's edge
cases all collapsed to two:</p>
<pre>    @var &lt;== LIST;
    LIST ==&gt; @var;</pre>
<p>Damian said that Larry was still unsure about these but that he
(Damian) thought they would be allowed in, if only because</p>
<pre>    @in ==&gt; map  {...}
        ==&gt; sort {...}
        ==&gt; map  {...}
        ==&gt; @out;</pre>
<p>is a lot less ugly than</p>
<pre>    @in ==&gt; map  {...}
        ==&gt; sort {...}
        ==&gt; map  {...}
        ==&gt; push @out;</pre>
<p>or (John Williams suggestion)</p>
<pre>    LIST ==&gt; @var.STORE(*);</pre>
<p>I have visions of the Perl 6 naysayers reading this section and
muttering dark imprecations about the end of the Perl as we know
it...</p>
<p><a href='http://groups.google.com/groups?threadm=BC6DD3EA-535B-11D7-8B38-00050245244A@cognitivity.com' target='_blank'>groups.google.com</a></p>
<a name='Complex Parameter Types'></a><h2>Complex Parameter Types</h2>
<p>Michael Lazzaro wanted to know more about 'complex' type
declarations. He wanted to know how these interacted with signatures,
could one use arbitrarily complex types in subroutine signatures? Could
one do multidispatch on them? He also had a question about
when/whether types got coerced (that wasn't actually his question, but
it's what it boiled down to) when functions were called.</p>
<p>The answer to the first two questions was straightforward: Yes, you
can use arbitrarily complex types in function and multimethod
signatures.</p>
<p>The third one proved a little trickier. Damian said that values would
not be coerced, but Larry wasn't so sure. He thought that coercion
would be the right thing to do. Probably. Damian noted that the 'Right
Thing' could well vary depending on whether the parameter in question
was declared <code>is constant/rw</code> (in which case passing a parameter with
the wrong type would be an error) or <code>is copy</code> (in which case
coercion could be the thing to do). Austin Hastings wondered if this
could be handled with a <code>use strict 'params'</code> type pragma, but Damian
wasn't convinced, arguing that the use of typed params automatically
implied type stricture.</p>
<p>This thread gets horribly hard to summarize so, for now, I'll just
pick out some representative highlights.</p>
<p>Larry says that, in the absence of a pragma to the contrary type
checking will be done at runtime if the type is unknown/unknowable at
compile time, but he expects the B&amp;D types to come up with a pragma
that enforces compile time checking on pain of failed compilations.</p>
<p>Brent Dax came up with the concept of 'strict' and 'loose' argument
typing. Strict arg typing doesn't coerce except that, say, a Child can
satisfy a requirement for a Parent. Loose arg typing will coerce
wherever possible. He argued that the mechanism for choosing between
strict and loose arg typing should be under the control of the
<i>caller</i> rather than the callee, as that seemed to fit best with The
Perl Way. Larry agreed with him. He added that the real question is
whether the default <code>use strict</code> should include strict arg typing and
noted that he was inclining toward the strict side. This week.</p>
<p>A subthread sprang up dealing with Type inference. David Whipp noted
that a smart compiler might well be able to infer the type of some
variables at compile time. The theory being that in the presence of
good type inference some variables wouldn't have to have a known type
to avoid triggering compile time errors under strict arg typing. Angel
Faus pointed out that using 'user visible' type inference wasn't too
good an idea because (among other reasons) it might lead to cases
where a program only works as written for more recent versions of the
compiler (which doesn't mean that type inference is a bad idea; if the
compiler knows the type of a variable it could potentially use that
information to improve code performance).</p>
<p>My head started spinning when Larry seemed to imply that, not only is
Int a Scalar, but a Scalar is also an Int. Or maybe it plays one on
TV.</p>
<p>This thread is still very much underway as I write this summary, so
attempting to summarize it is akin to summarizing a book when you're
halfway through it; you're never quite sure what are the important
bits. Hopefully things will be a little nearer resolution next week
and you'll get a more coherent summary of the conclusions.</p>
<p><a href='http://groups.google.com/groups?threadm=47347794-5363-11D7-8B38-00050245244A@cognitivity.com' target='_blank'>groups.google.com</a></p>
<p><a href='http://groups.google.com/groups?threadm=20030314033648.58654.qmail@onion.perl.org' target='_blank'>groups.google.com</a> -- the inference
subthread</p>
<p><a href='http://groups.google.com/groups?threadm=20030313195506.GA15015@wall.org' target='_blank'>groups.google.com</a> -- My head hurts</p>
<a name='Signatures zones and line noise'></a><h2>Signatures zones and line noise</h2>
<p>Brent Dax wasn't keen on the new syntax for declaring whether
parameters were optional, positional, named or variadic (greedy) and
wondered if we couldn't use something prettier (wordier) with named
traits (<code>$x is optional</code> etc). Damian thought that would be
'uncomfortably prolix' with default values ending up a long way from
their owners. Paul and Brent proposed allowing</p>
<pre>    multi substr(Str $str, $from = $CALLER::_ is optional
                           $len  = Inf is optional,
                           $new is optional) {
        ...
    }</pre>
<p>but Damian pointed out that this could lead to badness because, in a
signature the <code>is</code> would bind to the variable, but in a normal
variable declaration and assignment the <code>is</code> would bind to the value,
which would be confusing. There was some discussion of appropriate
names for the other 'linenoise' in signatures, specifically the choice
of name for the <code>*</code> type. The three front runners appear to be
'variadic', 'greedy' and 'slurpy/slurpificatious'. I like 'greedy',
but then I'm close to the person who proposed it.</p>
<p><a href='http://groups.google.com/groups?threadm=005401c2e798$49301b90$6501a8c0@deepblue' target='_blank'>groups.google.com</a></p>
<a name='In which Luke Palmer gets ignored'></a><h2>In which Luke Palmer gets ignored</h2>
<p>Luke Palmer had things to say about Appendix C of the apocalypse,
specifically to do with temp/let and with <code>caller</code> and
Continuations. Maybe what he said on these subjects was completely
uncontroversial, but nobody has replied to either of
them yet.</p>
<p><a href='http://groups.google.com/groups?threadm=ygc1y1eictl.fsf@babylonia.flatirons.org' target='_blank'>groups.google.com</a> -- temp/let</p>
<p><a href='http://groups.google.com/groups?threadm=ygcsmtu5h0l.fsf@babylonia.flatirons.org' target='_blank'>groups.google.com</a> -- Continuations</p>
<a name='Multi promotion'></a><h2>Multi promotion</h2>
<p>Richard Proctor wondered what would happen if you declared a
multimethod with the same name as a previously declared normal
sub/method. Specifically he wanted to know if the new declaration
would automagically turn the old one into a multimethod. Michael
Lazzaro thought not. As did Damian and Larry. Damian provided a
summary of the rules for subroutine/method dispatch, which look
wonderfully subvertable. Piers Cawley wondered if it would be possible
to get at a 'dispatcher' object and/or override it in a lexical scope,
nothing that sometimes, he scares himself. Nicholas Clark seemed to
think Piers wasn't completely insane before going on to talk about
wrapping and unwrapping in the case when the wrapper has itself been
wrapped. Larry seemed to think that unwrapping should still do the
right thing even if the wrapper being removed is itself wrapped.</p>
<p><a href='http://groups.google.com/groups?threadm=Marcel-1.53-0311144218-0b0Rr9i@waveney.demon.co.uk' target='_blank'>groups.google.com</a></p>
<p><a href='http://groups.google.com/groups?threadm=3E6E853D.9090604@conway.org' target='_blank'>groups.google.com</a> -- Dispatch rules (OK?)</p>
<a name='Wrappers vs. Efficiency'></a><h2>Wrappers vs. Efficiency</h2>
<p>In the Apocalypse, Larry talked about the performance implications of
generalized function wrappers and brought up the idea of subroutine
traits which would mark a sub as unwrappable, giving <code>is inline</code> as
an example. John Siracusa asked that whatever the 'specific definition
for speed' is that forbids runtime wrapping, it shouldn't be spelled
'inline' (though inline may imply &quot;don't wrap me please&quot;). A few
people agreed, but things mostly got left vague.</p>
<p><a href='http://groups.google.com/groups?threadm=BA93ED19.605E6' target='_blank'>groups.google.com</a>%siracusa@mindspring.com</p>
<a name='Macro invocants'></a><h2>Macro invocants</h2>
<p>Dave Whipp wondered about using macros to do things like:</p>
<pre>    my Database $db = MySqlDatabase.connect(...);
    $db.select * FROM Foo WHERE Foo.bar LIKE a%b;</pre>
<p>by implementing <code>select</code> as a macro. Larry thought so, but you would
have to export the macro into the calling context. Larry added that
you would probably implement that particular functionality by treating
&quot;.select&quot; as an infix macro with a specially parsed argument on its
right hand side (the SQL statement). David thought this was a little
clunky and proposed <code>macromethod</code> as a way to avoid the export
requirements. Luke Palmer was unconvinced and it went back and forth a
few times.</p>
<p>Larry wasn't convinced by David's suggestion either, commenting that
'mixing such compile-time semantics with a notation that supposedly
mandates run-time dispatch is a recipe for a certain amount of
confusion no matter how well we do it.'</p>
<p><a href='http://groups.google.com/groups?threadm=20030312013549.15320.qmail@onion.perl.org' target='_blank'>groups.google.com</a></p>
<a name='Overloading multis on constness of parameters'></a><h2>Overloading multis on constness of parameters</h2>
<p>Joe Gottman wondered if it would be possible to overload multimethods
based on the const-ness of a parameter is the same way C++ does. The
answer appears to be 'yes'. Piers Cawley passed on a question from
Greg MacCarroll about overloading on the value of a parameter. Damian
thought probably not, but then showed a cunning trick involving
overloading <code>isa</code> and a junction to allow something pretty similar.
Luke Palmer was impressed.</p>
<p>I'm not entirely sure what it had to do with this particular thread,
but Austin Hastings posted a chart of his understanding of the various
dispatch rules. Worth reading.</p>
<p><a href='http://groups.google.com/groups?threadm=004d01c2e83b$47b8c0c0$cf6e1918@carolina.rr.com' target='_blank'>groups.google.com</a></p>
<p><a href='http://groups.google.com/groups?threadm=20030314205347.31744.qmail@web12308.mail.yahoo.com' target='_blank'>groups.google.com</a> -- Austin's chart</p>
<a name='Operators and context'></a><h2>Operators and context</h2>
<p>Deborah Ariel Picket had some questions about Michael Lazzaro's
complete list of known Perl 6 operators, and wondered if this list
should be extended to take context into account. She also wondered
what the complete list of possible contexts was now. Michael reckoned
that the list she pointed to was still current, but he expected to add
the new <code>&lt;==</code> and <code>==&gt;</code> ops. He also agreed that adding
information about contextual behaviour would be a good (if daunting)
thing to do. He noted too that Apocalypse 6 seems to imply that there
would be a context for every type. Nothing definitive from Larry (or
even Damian) yet.</p>
<p><a href='http://groups.google.com/groups?threadm=200303130103.h2D13EY1026789@bruce.csse.monash.edu.au' target='_blank'>groups.google.com</a></p>
<p><a href='http://archive.develooper.com/perl6-language@perl.org/msg12130.html' target='_blank'>archive.develooper.com</a>
-- the current operators list</p>
<a name='Assignment Overloading'></a><h2>Assignment Overloading</h2>
<p>Luke Palmer wondered if it would be possible to overload the
assignment operator and wondered if the assignment operator was a
value or a reference copy. Damian pointed out that <code>*infix:=</code> was
really an operator on containers not values and you'd probably
implement it by overloading <code>STORE</code> in the container's class. He also
commented that <code>STORE</code> might end up being spelled
<code>&amp;infix:=</code>. Copying is a shallow value copy.</p>
<p>Larry popped up to discuss the .copy method on SCALAR but I wasn't
entirely sure whether that gets called on the target container or the
thing being copied. But that might just be me being confused.</p>
<p><a href='http://groups.google.com/groups?threadm=ygc7kb3d5pu.fsf@babylonia.flatirons.org' target='_blank'>groups.google.com</a></p>
<a name='P6FC'></a><h2>P6FC</h2>
<p>Aldo Calpini put up a tentative class hierarchy for Perl 6's standard
classes (he called them the Perl 6 Foundation Classes, narrowly
avoiding a knee jerk response from at least one summarizer of this
parish) and asked for comments. Murat &Uuml;nalan suggested that Aldo
was posting to the wrong audience before suggesting that we adopt the
.Net/Java object hierarchy, which confused Aldo somewhat, so Murat
clarified what he meant. Simon Cozens made a few suggestions to Aldo
about naming and missing classes. Larry added some clarifications on
his thinking about the difference between types and classes.</p>
<p><a href='http://groups.google.com/groups?threadm=20251014703.20030313105923@perl.it' target='_blank'>groups.google.com</a></p>
<p><a href='http://dada.perl.it/p6fc.html' target='_blank'>dada.perl.it</a> -- Aldo's class diagram</p>
<p><a href='http://groups.google.com/groups?threadm=20030314184631.GD22246@wall.org' target='_blank'>groups.google.com</a> -- Larry on types and classes</p>
<a name='Thoughts about multiple properties'></a><h2>Thoughts about multiple properties</h2>
<p>Chris Dutton wondered about using junctions for multiple properties
so <code>method bar is public is rw {...}</code> could be written as
<code>method bar is public &amp; rw {...}</code> instead. Jonathan Scott Duff
didn't think that made much sense, and pointed out that the <code>is</code> is
optional after the first, so you could write
<code>method bar is public rw {...}</code> if you wanted. Larry noted that 'that
feature is still in Schr&ouml;dinger's little box.'</p>
<p>This led Mark Biggar to suggest some syntax for neatly defining
groups of traits and complex types without having to go to the length
of defining a class. Michael Lazzaro thought that Perl 6 classes
wouldn't be as heavyweight as they are in Perl 5 and did some WAGging
(Wild Ass Guessing) about making subs that inherit from Sub which
looked pretty good to me even if it did lead Austin Hastings to call
Michael a 'bad, evil man'.</p>
<p><a href='http://groups.google.com/groups?threadm=37E62955-5584-11D7-A62F-0005020F8EB9@cmb-enterprises.com' target='_blank'>groups.google.com</a></p>
<a name='Named vs. Variadic Parameters'></a><h2>Named vs. Variadic Parameters</h2>
<p>Michael Lazzaro pointed up some issues with subroutines that have both
variadic arguments and named arguments. Luke Palmer thought that there
were two, mutually exclusive, ways of dealing with this: Michael's proposed
behaviour and the behaviour described in the Apocalypse. Luke was
happy with the Apocalypse behaviour. Michael said that he hoped that
whatever was decided, 'broken' function signatures would give rise to
a compiler error.</p>
<p><a href='http://groups.google.com/groups?threadm=59940A64-567C-11D7-895C-00050245244A@cognitivity.com' target='_blank'>groups.google.com</a></p>
<a name='is static?'></a><h2><code>is static</code>?</h2>
<p>Uri Guttman asked about static variables in Perl 6. In Perl 5 you can
get a static variable by doing:</p>
<pre>    {
        my $count = 0;

        sub sequence { return ++$count }
    }</pre>
<p>Uri wanted to be able to do something like:</p>
<pre>    sub sequence {
        my $count is static is default(0);
        return ++$count;
    }</pre>
<p>Dave Whipp wondered if <code>our</code> did the job (it doesn't). Larry
mentioned that he didn't particularly like 'static' as a name for this
sort of variable and reckoned that, if there were an 'is static'
declaration the compiler would probably translate:</p>
<pre>    my $pi is static = 3;</pre>
<p>to something like</p>
<pre>    our $foo__Xdeadbeef will init {.set(3)}</pre>
<p>Larry's preferred syntax would be <code>our $foo is unique</code>, but he noted
that 'It's not like someone isn't going to implement &quot;is static&quot; the
moment our back is turned anyway'.</p>
<p><a href='http://groups.google.com/groups?threadm=x7of4c7cj0.fsf@mail.sysarch.com' target='_blank'>groups.google.com</a></p>
<a name='No mandatory named arguments?'></a><h2>No mandatory named arguments?</h2>
<p>Nicholas Clark wondered if his reading of Apocalypse 6 was correct and
that there is no way to specify mandatory named parameters. Larry
agreed that this was so, but that one could finesse things at runtime
with tricks like:</p>
<pre>    sub foo(+$req = die 'You must supply a &quot;req =&gt;&quot; argument') {...}</pre>
<p><a href='http://groups.google.com/groups?threadm=20030315231648.GJ277@Bagpuss.unfortu.net' target='_blank'>groups.google.com</a></p>
<a name='Acknowledgements, Announcements and Apologies'></a><h1>Acknowledgements, Announcements and Apologies</h1>
<p>That about wraps it up for this week. Many thanks to Larry for giving
us all something to talk about on perl6-language this week; I was
starting to think about making the language list summary a fortnightly
thing.</p>
<p>If you appreciated this summary, please consider one or more of the
following options:</p>
<ul>
<li><a name='Send money to the Perl Foundation at donate.perl-foundation.org/ and help support the ongoing development of Perl.'></a>Send money to the Perl Foundation at
<a href='http://donate.perl-foundation.org/' target='_blank'>donate.perl-foundation.org</a> and help support the ongoing
development of Perl.</li>
<li><a name='Get involved in the Perl 6 process. The mailing lists are open to all. dev.perl.org/perl6/ and www.parrotcode.org/ are good starting points with links to the appropriate mailing lists.'></a>Get involved in the Perl 6 process. The mailing lists are open  to
all. <a href='http://dev.perl.org/perl6/' target='_blank'>dev.perl.org</a> and <a href='http://www.parrotcode.org/' target='_blank'>www.parrotcode.org</a>
are good starting points with links to the appropriate mailing lists.</li>
<li><a name='Send feedback, flames, money, job offers or a 'get out of war free' card to p<a href='mailto:6summarizer@bofh.org.uk'>6summarizer@bofh.org.uk</a>'></a>Send feedback, flames, money, job offers or a 'get out of war free'
card to <i><a href='http://search.cpan.org/perldoc?<a href='mailto:p6summarizer@bofh.org.uk'>p6summarizer@bofh.org.uk</a>'>p<a href='mailto:6summarizer@bofh.org.uk'>6summarizer@bofh.org.uk</a></a></i></li>
</ul>
<p>This week's summary was again sponsored by Darren Duncan. Thanks
Darren. If you'd like to become a summary sponsor, drop me a line at
<i><a href='http://search.cpan.org/perldoc?<a href='mailto:p6summarizer@bofh.org.uk'>p6summarizer@bofh.org.uk</a>'>p<a href='mailto:6summarizer@bofh.org.uk'>6summarizer@bofh.org.uk</a></a></i>.</p>
</div>
